III.FHIR 周邊內容

08 Implementation Guide、Profile、Bundle

前面談了這麼多的IG, Profile的，現在終於要正式來談他們了，

任何資料都有用途，有傳遞的對象、傳遞的內容與傳遞的原因與意義。

HL7的FHIR標準僅提供了一個主要的框架，告訴使用者這個標準之中有什麼可以用的資源，讓使用者自行去設定使用，

而回到實用立場，假設今天一個需要申請保險給付的患者需要將自己的資料送上去給保險公司評估是否達到出險標準，

保險公司勢必需要訂出一個他所需要的資料欄位，就跟原先做任何出險申請時的流程一致，只是現在把資料嵌套進去FHIR內了，

前面有提過，FHIR本身支援Extension欄位，能夠將一些沒有在主框架上的欄位進行客製化調整，可以滿足因地制宜的解決方法，

那麼，剩下來的問題就很簡單了，如上面的那個例子，保險公司只要將自己的需求欄位重新設計成FHIR的格式，要求申請人將自己的資料填入並上傳即可，

這就是Implementation Guide實作指引，簡稱IG的最簡單定義。

第二個問題是，如果每一家保險公司都自己設計他們所需要的欄位，自己添加Extension，對申請者來說遇到的狀況是，

倘若今天我轉移保險到其他家公司，這意味著原先上繳的欄位就不一定滿足現在這家保險公司所需要，並且同樣的屬性卻要放在不同的FHIR欄位中，

所以建立一個共通的，或是基礎的IG變得非常重要，若有一個共通的IG可用，申請人在面對不同的保險公司提交時僅需修改Extension自訂欄位即可，

原先各自為政，自主定義的方式又等於是再次讓資料重回資料孤島，只是將資料轉換成FHIR格式，但並沒有實際真正完成統一的資料格式。

私人企業在定義互通標準的難度會相對比較高一些，但官方的力量就不一樣了，

針對每個國家有不同的文化定義，國家可以先定義一個最基礎的需求欄位標準，在這裡會稱為Core IG(核心指引)，

用比較簡單的話來說，就是國家根據HL7 FHIR標準，先建出一個國家通行使用的FHIR標準，
各單位的需求與接受所設計的IG可以用Core IG作為指引參考，因為設計的IG是繼承Core IG，所以不同的IG設計都可以保持一定程度的欄位共通性，

所以IG的概要定義是：要如何使用一些FHIR Resource的規則來處理特定的需求或問題，

IG Hierarchy (HL7 Communities Sprial) - Diego Kaminker

-----------------Implementation-----------------

Level 1  Core Standard Developers   EX:HL7, HL7 Canada

Level 2  Realm Specific Core IG Developers EX:TW core
 
Level 3  Accelerators      EX:Davinci, mCode STU3

Level 4  Implementer - Developer

Level 5  Implementer - Site

---------------Community Outreach---------------

Level 6  Existing Communities

Level 7  New Communities

IG可以從發布的網站中尋找到整個package或指引，當使用者將pacakge.tgz壓縮包下載後，可以透過一些方式將這包package匯入至FHIR Server內，

在日後搜尋資料或執行驗證時，FHIR Server可以根據已匯入的IG內容進行驗證與參照，包括Terminology的驗證。

知道IG具體是什麼了之後，這裡可以往下談到Profile，

在IG中，Profile是實際定義欄位的文件，通常型態是StructureDefinition，
這個Resource告訴使用者該怎麼使用這個Profile來實作某個特定的Resource以達成IG設計者想要得到的資訊，

聽起來有點繞口，以實際案例來說，Claim Profile這個文件是告訴使用者該怎麼樣實作Claim，這些欄位間有哪些限制(cardinality, constraints)等

在閱讀一個Profile的StructureDefinition時，請優先將Profile Content切換到Snapshot Table，可以相對好進行完整內容的閱讀，

就如同閱讀FHIR Resource的定義相同，閱讀一份Profile最先需要關注的是Table內的Cardinality, Description & Constraints，

這些欄位告訴使用者或實作者，這些表列的欄位應該如何被填寫，有哪些限制，使用者只需要遵照這些限制規則就能把設計者所需的欄位放置妥適。

這時候我想大家可以注意到一個隱藏的問題，假設保險公司受理出保的表單規則不清，會發生什麼事情?

本篇系列文不會去談到建立、設計IG的部分，在此筆者以使用者或實作者的角度來看，

因為FHIR IG是任何人都能使用、申請註冊的，設計IG的人員要清楚理解這份IG所需要解決的問題是什麼，

而且對於每一個所需的欄位，絕對不可以定義不明或隨意帶入限制，撇除臨床或應用意義上的不合理之外，

對於實作者來說會非常困擾，前幾天有提到欄位的影響，在臨床判斷來說，任何一個數據的偏誤都可能會導致臨床上的誤診，

當要提交的申請文件內容是曖昧不清的，資料汙染的下場就是雙方都得花更多時間來做勘誤。

除了閱讀Table外，筆者會特別建議先去往下滑到該Profile中所列的Terminology Bindings與Constraints
這兩個列表能最快速的讓實作者了解到這個Profile中所使用的Terminology與Constraints，值得注意的地方是，

Constraints的欄位中會分別列出該Constraints的定義，以及對應的FHIRPath語法，也就是說，
可以透過對這些Constraints等欄位的FHIRPath語法來檢驗特定FHIR Resource的欄位是否有填答錯誤或格式不符

最後來補回講 Bundle這個Resource，之前有提到過，Bundle作為表單申請最上層的Resource，下轄各式各樣的Resource，

但Bundle的作用不只限於此

https://www.hl7.org/fhir/bundle.html

從Bundle內的type binding中可以看到

https://www.hl7.org/fhir/valueset-bundle-type.html

bundle的型態決定了

1. 用來組合Resource的Resource型態
    Document -> Composition
    Message -> MessageHeader

2. Bundle的用途以及出現場合
    Batch -> 一連串FHIR操作的集合
    SearchSet -> FHIR Server回傳的查詢結果集合
    Subscription-notification -> 生成訂閱與溝通資訊
    
   較為功能性質的Bundle型態通常是由FHIR Server實作，與使用者溝通，
   而定義一組Resource集合，作為向上溝通用途的Bundle，通常為IG制定，

以Batch來說
https://outburn.health/updating-multiple-resources-using-patch-operation-the-easy-way-explained/

這個Bundle可以批次完成上傳FHIR Resource的方法，
作法是將Resource的本文壓成Base64的型態，仿照RESTAPI的格式將Resource逐一上傳

bundle作為資料交換的核心Resource，其用途不僅體現在上傳上，也在FHIR Server的互動介面中占據非常重要的地位。

到這邊關於FHIR的基本概念與知識術語等差不多介紹完了，上段的內容若有需要補充的我會再編輯添加，
因為光是概念性的東西就很不好入手了，涉及的範圍太廣太大，
今天所談到的IG，若有興趣的讀者想要深入研究可以去研究一下FSH與sushi，但本篇系列文並不涉及IG的創建與發布，

對於這些概念性的知識，在文章的後續實作階段會更容易理解，現階段釐清這些名詞術語的用途與概念即可

終於要進入中段了，中段會主要聚焦在如何建出一個可以用來測試的FHIR Server，
本篇系列文會使用Docker來處理，但筆者個人會較為推薦使用maven來建置HAPI FHIR Server，
在Docker上建置HAPI FHIR吃的虧太多了，但也因此找到一些奇妙的解決方法，後面會再分享